-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Add publish confirmation prompt #96
Conversation
0018-publish-prompt.md
Outdated
|
||
## Implementation | ||
|
||
This is a breaking change from the current `npm publish` behavior, it would prompt the user for confirmation: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps a good first step would be, provide an option to enable the prompt, and then change the default in a future major?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could just make the default be --yes
when process.stdout.isTTY === false
. Then it'll keep on working for build scripts and CI, but prompt everyone on the CLI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have plans to align with other package managers? Would be great to have a consistent behavior, I think this is a great idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I think we would do this as well in Yarn. cc @zkochan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine for single-package scenario but I am not sure this would work during a publish in a monorepo. I doubt that someone would review the content of every published package if dozens are published.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if it would only show the prompt if the list of files that are published differs from the list of files in the previously published version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all monorepos publish multiple packages at once; in my experience many use independent versioning at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Printing a file diff if possible could be interesting 🤔
Something else to consider is that workflows publishing multiple packages (which do exist, for example this is what we do on Yarn, and I think Babel and Jest do the same) might be more likely to just use --yes
(which would be handy, but would kinda negate this RFC altogether).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
multiple packages is common; "bumping all package versions at once even if they haven't changed, to keep all versions the same" is the original lerna behavior that babel, and many others, have thankfully abandoned :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarifying Lerna behavior for future reference:
"bumping all package versions at once even if they haven't changed, to keep all versions the same"
This isn't actually what Lerna does in the default "fixed" versioning scheme. It applies a single version to any package (and its local dependents) that has changed since the previous release (annotated git tag).
Not all monorepos publish multiple packages at once; in my experience many use independent versioning at this point.
"Independent" versioning doesn't change anything about how Lerna detects changes between releases or bumps dependents of changed packages, it merely allows one to choose versions per-package instead of globally.
Notes from the OpenRFC call:
|
b1763f9
to
445af22
Compare
Updated contents of the RFC based on feedback collected during the OpenRFC call and the comments left here 😊 should be ready for ratification if no contention point is raised |
Co-Authored-By: Jordan Harband <[email protected]>
…o/rfcs into add-publish-confirmation-prompt
cleaned up the RFC and documented all feedback collected 👍 should be good to go |
Is it possible to make the files listed in Tarball Contents be sorted alphabetically? |
@eridal that does sounds a bit outside of the scope of this RFC but that said, it would def be nice to have! 👍 |
- Changed opt-in flag name to remove reference to "experimental"
Updated with feedback from the OpenRFC call removing "experimental" from the name of the option/flag. |
@ruyadorno thanks for your answer Does that happens here? https://github.com/npm/libnpmpack/blob/ebe5d4790f61f93c7045dd0341f61681ed520899/utils/tar.js#L18 I'd like to attempt to submit a separate PR to address that feature, but that module seems to be currently worked on |
@eridal Yes, that's currently being worked on by @claudiahdz. Publish and pack will both use the same code path for displaying the tarball contents, and presumably we'd leave that untouched by this RFC. Sorting should be straightforward, I'd think, but I recommend you post an issue on https://github.com/npm/libnpmpack, just so that there's a thing to track. |
This will make `npm pack` output the tarball contents in an alphabetically and natural sort order. The current implementation uses `localeCompare` with the following options: 1. **sensitivity**: `base`, to correctly handle non-ascii letters using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are all handled like `a` 1. **numbers**: `true`, to handle numeric filenames as natural ascending order so that, for instance, file `10.txt` appears after `9.txt` --- Convo from npm/rfcs#96 cc @ruyadorno @isaacs
This will make `npm pack` output the tarball contents in an alphabetically and natural sort order. The current implementation uses `localeCompare` with the following options: 1. **sensitivity**: `base`, to correctly handle non-ascii letters using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are all handled like `a` 1. **numbers**: `true`, to handle numeric filenames as natural ascending order so that, for instance, file `10.txt` appears after `9.txt` --- Convo from npm/rfcs#96 cc @ruyadorno @isaacs
This will make `npm pack` output the tarball contents in an alphabetically and natural sort order. The current implementation uses `localeCompare` with the following options: 1. **sensitivity**: `base`, to correctly handle non-ascii letters using their base ascii, so that `á`,`â`, `ä`, `ã`, `å` are all handled like `a` 1. **numbers**: `true`, to handle numeric filenames as natural ascending order so that, for instance, file `10.txt` appears after `9.txt` --- Convo from npm/rfcs#96 cc @ruyadorno @isaacs
Landed in 0ad3bdc |
npm publish
should have a confirmation prompt in order to provide a chance for users to review the package contents, similar to how 2FA-enabled users are able to review the contents prior to inputting their OTP.See RFC
/cc @mikemimik